docs(site): drop the v3.5 pruning migration note - #23345
Draft
bloxster wants to merge 1 commit into
Draft
Conversation
…lies The note documented the v3.4 → v3.5 change to --prune.mode=full. Its steady state is already described in the table and the per-mode sections, so what remained was a version diff plus one wrong instruction: --prune.distance.blocks is a Uint64Flag, so the suggested `--prune.distance.blocks=keep-post-merge` cannot parse. Fold the two parts that are not version-specific into the mode descriptions — that pruning cannot be undone without a re-sync, and that a Full Node cannot serve history beyond its window, for which the Blocks Node is the answer. Co-authored-by: Bloxster <gianni.morselli@erigon.tech> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copilot stopped reviewing on behalf of
bloxster due to an error
August 17, 2026 14:12
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Removes the
Breaking change in v3.5admonition from the Pruning Modes page, keeping the parts of it that are not version-specific.Why
The note is addressed to a reader who no longer exists. It is a v3.4 → v3.5 upgrade notice sitting near the top of the current docs, which now describe v3.6. A "breaking change in v3.5" is simply not news to someone running 3.6 — the break is two versions behind them, and the page already carries an
As of v3.6tip directly above it. Anyone actually upgrading to v3.5 still gets the note in the versioned archive at/v3.5/, which is where version-specific migration guidance belongs.Its steady state is also already documented permanently: the retention behaviour it announced is stated in the comparison table and in the Full Node / Blocks Node / Minimal Node sections — the EIP-8252 window, 262,144 blocks (~36.4 days), and what each mode prunes. What was left in the note was a v3.4-vs-v3.5 diff.
One incidental find while removing it: the note told operators to
set --prune.distance.blocks=keep-post-merge, but that flag is acli.Uint64Flag(node/cli/flags.go), so it accepts only a number and the suggested command cannot parse. The equivalent is the sentinel18446744073709551615(KeepPostMergeBlocksPruneMode = Distance(math.MaxUint64)), not worth putting in front of readers.release/3.5was already corrected and drops that wording;mainandrelease/3.6still carry it.What was kept
Two statements in the note were durable rather than version-specific, so they moved into the mode descriptions:
Net: −24 lines, +6.
Verification
generate-llms.py --checkgreen (73 pages),tsc --noEmitclean,npm run buildSUCCESS.llms.txt/llms-full.txtregenerated (the page feeds them).onBrokenAnchors: 'throw', so the new#blocks-nodelink is verified to resolve.Notes for reviewers
mainandrelease/3.6share this page, so this needs a forward-port torelease/3.6to survive the docs cutover — happy to open that, or fold it into #23283 which already targets that branch.Separately, and not touched here: the Minimal Node paragraph says it "does not retain state history", while the table says it keeps state within the last 100,000 blocks. The table matches the source (
MinimalModesets bothBlocksandHistoryto 100,000). Worth a follow-up.